1. Field of the Invention
This invention relates to controlling the instruction processing rate of a digital data processing system; and, more particularly, to regulating the processing rate on an instruction-by-instruction basis during the execution of a computer program.
2. Description of the Prior Art
In digital processing systems, it is often desirable to control the execution rate of an instruction processor (IP). Controlling the processing rate may be useful for several reasons. First, slowing the execution rate may provide a temporary solution to hardware problems discovered during system test. This is because many hardware problems uncovered during full-speed system test do not manifest themselves when the IP is executing at a slower rate. Slowing the execution rate can therefore provide a temporary solution until a permanent design fix can be implemented.
Slowing the execution rate can be particularly effective for implementing temporary fixes in pipelined IPs. In pipelined IP architectures, several instructions are resident within the IP at the same time in various stages of execution. For example, the IP hardware may be simultaneously executing the hardware sequences associated with the Nth instruction, fetching an operand in preparation for execution of the Nth+1 instruction, and performing the initial decode for the Nth+2 instruction. This is referred to as having multiple instructions "in the IP pipeline". Pipelined architecture increases system throughput by allowing multiple instructions to be executing at the same time.
Often during system test, design problems are uncovered because the hardware sequences associated with two pipelined instructions result in unforeseen interaction. For example, the hardware sequences associated with the decode of a particular Nth+2 instruction may interfere in an unforeseen manner with the operand fetch of the Nth+1 instruction. Often such problems will not be manifested if the IP throughput is slowed down so that the Nth+1 Instruction is completely executed before the Nth+2 instruction is read into the IP pipeline. This is called "de-piping" the IP. Controlling the IP execution so that an IP can be de-piped is a useful means of implementing temporary "work-arounds" during hardware test until permanent design fixes are available.
The ability to vary an IP's execution rate can have useful applications in addition to those associated hardware test. For example, the ability to vary an IP's execution rate can allow a single processor design to be used within several different computing systems. Today, digital processing systems can range from very large high-speed mainframe systems to small desk-top models. A high-speed system having a large high-speed memory and a large bandwidth memory interface is generally designed to interface with a high-speed processor. The smaller midrange or desktop computing system, which may have a smaller, slower memory, and which may interface to slow peripheral devices, may require a slower IP. By using an IP with a variable execution rate, the same IP design can be integrated within both the high-speed systems and the slower machines. This spreads IP development costs over several products. It also lowers the cost of any custom-made silicon devices used in the IP design by increasing the production volume of such chips.
In prior art digital processing systems, several methods are typically used to vary a system's execution rate. One method used to adapt fast IP designs to slower machines involves slowing down IP execution using interrupts generated by the operating system. An interrupt is sent from the operating system to the IP after the execution of every instruction. The associated interrupt handler does nothing but "waste" IP time, thereby throttling the IP execution rate. This method can be useful, for example, in matching an IP request rate to a slower memory device.
This method has several disadvantages. First, it is not transparent to the hardware used for system time calculations. Generally, multi-user systems have a system timer which is used for billing purposes. This system timer records the amount of processing time used by each user. Users are only billed for the processing time spent doing productive work, not the time "wasted" in the slow-down interrupt handlers. However, the system timer, which is generally clocked by the system clock, can not distinguish between productive and "wasted" time. Therefore, billing records must be adjusted manually to take into consideration the slow-down mechanism.
In addition, using the operating system to implement slow-downs does not slow instruction execution at the hardware level. This method is therefore not effective to de-pipe an instruction processor so that temporary hardware work-arounds can be implemented during test.
Another method of controlling the execution rate of an IP can be used to implement hardware work-arounds. This method involves controlling the IP microcode sequencer. Most IP hardware designs have microcode sequencer logic which contains memory devices and associated control logic. The memory devices contain the digital data needed to initiate and control the hardware sequences for each IP instruction. Embedding a no-operation, or "NOP", instruction within the IP microcode causes the IP to pause and do nothing for a clock cycle, thereby effectively slowing the processing rate.
This method has advantages over using operating software to control the processing rate. First, by inserting NOPs within the IP microcode for a specific instruction, delay is actually inserted during the early decode stages of that instruction. This delay allows all prior instruction within the IP pipeline to complete execution so that the IP is de-piped before the specific instruction is decoded within the pipeline. As discussed above, de-piping the machine can often provide hardware work-arounds for problems discovered during test until more permanent fixes can be implemented. This method can therefore provide hardware work-arounds on an instruction-by-instruction basis. Second, since the processor rate is being slowed at the hardware level, instead of in software, the slow-down is completely transparent to users, and any software (including the operating system) developed for the IP.
Slowing the processing rate by altering IP microcode has several drawbacks, however. It is common that often the IP microcode RAM has only a limited amount of space. Spare memory locations may not be available to insert delays where needed. In addition, some IP microcode is included in ROM. Since the ROM is not modifiable, NOP instructions can not be added to this code.
Still another method of varying processing speed involves using a programmable clock generation circuit as disclosed in Branson, U.S. Pat. No. 4,819,164. This clock generation circuit interfaces to a processor, and can be programmed by the processor to produce a system clock of a desired frequency. Changing the clock frequency therefore requires the processor to write a control register in the clock generation circuit.
The circuit disclosed by Branson is not a practical means of varying execution rate on an instruction-by-instruction basis during system test. Since each frequency change requires a processor access to the clock generation circuit, instruction sequences can not be tested on a real-time basis. The delay imposed by the frequency changes can not be controlled on a clock-cycle basis, and may mask other timing problems that would otherwise be uncovered.
U.S. Pat. No. 4,947,411 to Shiraishi et al. discloses still another method of controlling processor execution rates. In the disclosed method, a variable frequency divider supplies the clock signal to the processor. One or more processor address bits interface with the frequency divider to control the frequency-dividing factor. The processor execution rate therefore varies depending on where the processor is executing within its own address space.
Although the method disclosed by Shiraishi et al. can be used to slow the clock to the processor, it is not useful in slowing execution of an instruction once the instruction is read into the IP. In other words, it can not be used to de-pipe the machine. Furthermore, this method is not very flexible, since segments of memory are "hardcoded" to certain execution rates. As with the Branson invention discussed above, this method does not allow Execution rates to vary on an instruction-by-instruction basis depending on the specific instruction being executed.